Skip to content

chore: CLI launch internal CI#3695

Open
ko3n1g wants to merge 5 commits intoNVIDIA:mainfrom
ko3n1g:ko3n1g/chore/launch-internal-ci
Open

chore: CLI launch internal CI#3695
ko3n1g wants to merge 5 commits intoNVIDIA:mainfrom
ko3n1g:ko3n1g/chore/launch-internal-ci

Conversation

@ko3n1g
Copy link
Contributor

@ko3n1g ko3n1g commented Mar 4, 2026

What does this PR do ?

Adds a CLI tool that makes it easy to test a public GH against the internal CI. For more details, please check out the README.

Contribution process

flowchart LR
    A[Pre-checks] --> B[PR Tests]
    subgraph Code Review/Approval
        C1[Expert Review] --> C2[Final Review]
    end
    B --> C1
    C2 --> D[Merge]
Loading

Pre-checks

  • I want this PR in a versioned release and have added the appropriate Milestone (e.g., Core 0.8)
  • I have added relevant unit tests
  • I have added relevant functional tests
  • I have added proper typing to my code Typing guidelines
  • I have added relevant documentation
  • I have run the autoformatter.sh on my PR

Code review

The following process is enforced via the CODEOWNERS file for changes into megatron/core. For changes outside of megatron/core, it is up to the PR author whether or not to tag the Final Reviewer team.

For MRs into `main` branch

Feel free to message or comment the @mcore-oncall to help accelerate your merge into main. The less complex your PR is, the faster it will be approved and merged!

(Step 1): Add PR label Expert Review

(Step 2): Collect the expert reviewers reviews

  1. Attach the Expert Review label when your PR is ready for review.
  2. GitHub auto-assigns expert reviewers based on your changes. They will get notified and pick up your PR soon.

⚠️ Only proceed to the next step once all reviewers have approved, merge-conflict are resolved and the CI is passing.
Final Review might get declined if these requirements are not fulfilled.

(Step 3): Final Review

  1. Add Final Review label
  2. GitHub auto-assigns final reviewers based on your changes. They will get notified and pick up your PR soon.

(Optional Step 4): Cherry-pick into release branch

If this PR also needs to be merged into core_r* release branches, after this PR has been merged, select Cherry-pick to open a new PR into the release branch.

For MRs into `dev` branch The proposed review process for `dev` branch is under active discussion.

MRs are mergable after one approval by either eharper@nvidia.com or zijiey@nvidia.com.

Merging your PR

Any member of core-adlr and core-nemo will be able to merge your PR.

Signed-off-by: oliver könig <okoenig@nvidia.com>
@svcnvidia-nemo-ci svcnvidia-nemo-ci added this to the Core 0.16 milestone Mar 4, 2026
@svcnvidia-nemo-ci svcnvidia-nemo-ci requested a review from a team March 4, 2026 10:05
Signed-off-by: oliver könig <okoenig@nvidia.com>
@ko3n1g ko3n1g requested a review from a team as a code owner March 4, 2026 10:21
Signed-off-by: oliver könig <okoenig@nvidia.com>
Signed-off-by: oliver könig <okoenig@nvidia.com>
@ko3n1g ko3n1g requested review from a team and Phlip79 March 4, 2026 10:27
Signed-off-by: oliver könig <okoenig@nvidia.com>
**1. Add the internal GitLab as a git remote** (skip if you already have one configured):

```bash
git remote add gitlab git@<gitlab-hostname>:<namespace>/<project>.git
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this the same for everyone?

@@ -0,0 +1,73 @@
# trigger_internal_ci.py

Pushes the current branch to the internal GitLab remote and triggers a CI
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would mention that this is only available to NVIDIA internal employees.

@@ -0,0 +1,73 @@
# trigger_internal_ci.py
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# trigger_internal_ci.py
# Trigger Internal CI


Reach out to @mcore-ci in case you don't have access to the settings page.

```bash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe mention this should be added to ~/.bashrc?

@ko3n1g
Copy link
Contributor Author

ko3n1g commented Mar 4, 2026

/claude review

2 similar comments
@ko3n1g
Copy link
Contributor Author

ko3n1g commented Mar 4, 2026

/claude review

@ko3n1g
Copy link
Contributor Author

ko3n1g commented Mar 4, 2026

/claude review

Comment on lines +13 to +14

To check existing remotes: `git remote -v`
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing prerequisite: users need to install python-gitlab before running the script. Without it they'll get ModuleNotFoundError: No module named 'gitlab'. Please add an install step:

Suggested change
To check existing remotes: `git remote -v`
**3. Install the required Python dependency:**
```bash
pip install python-gitlab

Comment on lines +151 to +157
gitlab_hostname = get_gitlab_hostname(remote_url)

target_branch = f"{GITLAB_BRANCH_PREFIX}/{branch}"

git_push(args.gitlab_origin, target_branch, dry_run=args.dry_run)

pipeline_vars = {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FUNCTIONAL_TEST is never explicitly set in pipeline_vars, so the tool silently relies on the GitLab CI YAML default ("yes"). If that default ever changes, functional tests will stop running without any warning. Consider making it explicit:

Suggested change
gitlab_hostname = get_gitlab_hostname(remote_url)
target_branch = f"{GITLAB_BRANCH_PREFIX}/{branch}"
git_push(args.gitlab_origin, target_branch, dry_run=args.dry_run)
pipeline_vars = {
pipeline_vars = {
**PIPELINE_VARIABLES_FIXED,
"FUNCTIONAL_TEST": "yes",
"FUNCTIONAL_TEST_SCOPE": args.functional_test_scope,
"FUNCTIONAL_TEST_REPEAT": str(args.functional_test_repeat),
"FUNCTIONAL_TEST_CASES": args.functional_test_cases,
}



if __name__ == "__main__":
main() No newline at end of file
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing newline at end of file.

@claude
Copy link

claude bot commented Mar 4, 2026

Code Review

Overall the tool is clean and well-structured. A few issues to address:

Bugs / logic gaps

  • FUNCTIONAL_TEST is never included in pipeline_vars, so the tool silently depends on the GitLab YAML default being "yes". This is fragile — explicitly pass "FUNCTIONAL_TEST": "yes" in the dict. (inline comment on trigger_internal_ci.py L151–157)

Missing documentation

  • The README has no step to install the python-gitlab dependency. Without it users immediately hit ModuleNotFoundError. Add pip install python-gitlab to the Prerequisites section. (inline comment on trigger_internal_ci.md L13–14)

Minor

  • trigger_internal_ci.py is missing a trailing newline at EOF.
  • In get_gitlab_hostname, the .split(":")[0] after urlparse(...).hostname is redundant — urlparse().hostname already strips the port — but it's harmless.

@Phlip79 Phlip79 added the Expert Review Apply this label to indicate that your PR is ready for expert review. label Mar 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Expert Review Apply this label to indicate that your PR is ready for expert review.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants